Modern computing systems often provide the ability to “undo” certain operations. This is because computer operators or the programs they use sometimes make mistakes. When mistakes happen, the operator may want to go back to a known state and try again. A variety of actions can lead to these mistakes. For example, programmers sometimes fail to recognize that a computing system will be used in a particular way. When the programmer has not tested for a particular use-case, a user may introduce errors into the system. In more complicated business transactions, it is common for many changes to be made over a variety of computing systems. If a change is made to one of these computing systems after such a multi-step business transaction begins, but before it ends, inconsistencies may be introduced into the system. This is especially problematic when the intervening change involves a security inconsistency with other changes made in the business transaction.
Some database systems have an advantage when it comes to ensuring consistency during database transactions. This is especially true of databases that implement ACID transactions, such as database systems provided by Oracle Corporation. ACID stands for Atomicity, Consistency, Isolation, and Durability. In database computing, atomicity means that if a sequence of changes are made within a single database transaction, either all of the changes will be made or none of the changes will be made at all. In other words, ACID transactions take an “all or nothing” approach. Thus, database systems can ensure that an entire transaction will be successful before committing that transaction.
Other computing systems do not have the luxury of the consistency provided by database systems. For example, LDAP (Lightweight Directory Access Protocol) based systems do not have built-in consistency checks before committing changes. Web services and other systems also commit changes as they are provided, even if those systems use databases to store information. For example, one of the changes required by a business transaction may be an update request to a web service. Although the web service may store data in a modern database, that database is unaware of any other changes required by the business transaction because only one change at a time is requested through the web service, and the web service merely makes changes as they are requested. The database then commits each transaction provided to the database in turn, even though other steps are required to complete the overall business transaction.
In the example provided above, it is possible that one of the operations will fail. For example, the business transaction may require thirteen separate steps to be taken, and the twelfth step may fail, causing an inconsistency over the systems. Such an inconsistency is problematic within a single system, but business transactions may require steps to be taken over multiple systems, compounding the problem.
One potential solution to this problem is to program special-purpose “undo” logic for each system or service for which undo capability is desired. However, maintaining hard-coded undo logic within a changing system is difficult, and often leads to errors. In addition, labor costs are too high. Writing undo logic to perform all of the necessary operations to rewind a failing business transaction is complex, and becomes very difficult as the number of operations that need to be dynamically generated by the logic increases. In addition, undo logic implemented in this way becomes invalid each time the service changes, resulting in a need for the code to be re-written.
What is needed is a general-purpose undo system that provides undo functionality for business transactions that occur outside of the comfort of a database transaction.